home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / ucp / ucp-minutes-90july.txt < prev    next >
Text File  |  1993-02-17  |  8KB  |  217 lines
  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Dan Long/BBN
  7.  
  8. UCP Minutes
  9.  
  10. Agenda
  11.  
  12.  
  13.    o Introduction to UCP Working Group:
  14.  
  15.       -  What is it?  What's been done so far?
  16.       -  Discussion of Matt Mathis' National Trouble Ticket Tracking
  17.          writeup.
  18.       -  Discussion of some operational issues by MERIT.
  19.       -  What's Next?
  20.  
  21.  
  22. Dan Long (Chair) presented a brief history of the UCP Working Group:
  23.  
  24.  
  25.    o FSU IETF: Initial discussion
  26.  
  27.       -  Structural proposals presented
  28.       -  Refine goals/scope
  29.       -  Writeups by Craig, Elise, & Martyne
  30.  
  31.    o PSC IETF: Definition of terms:
  32.       -  NSC (Network Service Center)
  33.       -  P1 (user<->NSC communication protocol)
  34.       -  P2 (NSC<->NSC communication protocol)
  35.       -  Writeup by Matt
  36.  
  37.  
  38. Matt Mathis (PSC) reviewed his description of a National Trouble Ticket
  39. Tracking system.  A lively discussion ensued about various aspects of
  40. the proposal including:
  41.  
  42.  
  43.    o How do you define ``closure with the user'' (as in ``a ticket is a
  44.      contract to obtain closure with a user'')?
  45.  
  46.       -  What do you do about uncooperative NOC's?
  47.       -  What do you do when you cannot satisfy the user due to
  48.          funding/engineering constraints?
  49.       -  Transfer of a ticket is a mechanism for obtaining closure and
  50.          resolving the problem.  We should acknowledge that certain
  51.          problems can't be closed in a technical sense.  This may be
  52.          sufficient for closure with the user.
  53.  
  54.    o What are the organizational implications of declaring a ticket to
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.      be a ``contract''?
  64.       -  Does that mean the NSC must respond to any old barage of
  65.          (nuisance) questions?
  66.       -  Can an organization commit to adhering to this system without
  67.          knowing the expected demand?
  68.    o How are NSC's ``certified'' (as in ``NSC's must be certified at
  69.      least as far as adherence to the rules described in this
  70.      document'')?
  71.  
  72.       -  We don't want to be (or can't be) coercive.
  73.       -  Needs some element of informal (polite) coercion rather than
  74.          legal coercion.  The problem is to get somebody to start owning
  75.          the problem and a way of recording where the problem lies.
  76.       -  Makes more sense to have the system be so useful that everyone
  77.          will want to join and conform.
  78.       -  Certification should only be that the NSC's adhere to the
  79.          ticket hand-off protocols.  Details of P2 protocol need to be
  80.          fleshed out by the person who sets up the TTC.
  81.  
  82.    o What about peer-bashing (i.e., pointing fingers, blaming,...)?
  83.  
  84.       -  It's self-regulating (...glass houses...stones...).
  85.       -  Would a national ombudsman be reasonable?
  86.  
  87.    o What about lots of users complaining about the same problem?
  88.  
  89.       -  Have multiple user dialogs cross referenced with a single
  90.          ``problem'' which has the other dialogs.
  91.       -  Closure should be obtained with each user.
  92.       -  We do want to track each caller so we know how many complaints
  93.          there are.
  94.  
  95.    o What about privacy of ticket information?
  96.       -  Tickets should be readable only by the owner and the ticket
  97.          arbitrage center (TAC).
  98.    o What do you do with the Engineering Dialog results?
  99.  
  100.       -  If the Engineering Dialog results in suggested improvements,
  101.          how do those get handled?
  102.       -  Does everyone who hears about the suggestions understand the
  103.          possible implementation obstacles?
  104.  
  105.  
  106. Dale Johnson (Merit) led a discussion on some aspects of this system not
  107. covered in the document:
  108.  
  109.  
  110.    o Any national Ticket Tracking system will have to be used in
  111.      conjunction with local systems.  For large sites which have
  112.      elaborate highly customized systems of their own, this might
  113.      require software to automatically copy tickets between the local
  114.      and national system.  Making the national system available for all
  115.      networks' local tickets could simplify operations for many NOCs,
  116.  
  117.                                    2
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.      although this could result in an extremely expensive national
  125.      system.  If the national system was freeware or was reasonably
  126.      available, then NOCs could at least use the same software for both
  127.      their local and national tickets.
  128.    o NSC's still need the tools to do the diagnosis.  Especially
  129.      important is contact information for different network entities.
  130.      The NNSC Phone Book may help solve this problem.  Contact
  131.      information should be both published and online.
  132.    o The NJM Working Group has started discussing common data formats
  133.      and access mechanisms for the routine (SNMP and other) data that
  134.      NOCs collect.  Access to this kind of data from other networks
  135.      could become very useful when a NOC tries to debug a complex
  136.      problem outside of its own jurisdiction, or when another entity
  137.      wants to aggregate or contrast data from different NOCs.  NJM will
  138.      continue with this project, but noted that this might also be
  139.      interesting to the UCP group because it is a form of inter-NOC
  140.      communication.
  141.    o How can we alert network users about outages, both planned and
  142.      unplanned?  How about an X.500-based (or DNS-based) posting system
  143.      that people (and network utilities?)  can query to determine the
  144.      operational status of various network components?  There was a fair
  145.      amount of discussion about a low-tech short-term solution involving
  146.      a standard format for problem reports posted to the NSR mailing
  147.      list.  The thought was that these standard reports could then be
  148.      automatically collected for occasional perusal/reference by NSC
  149.      staff.
  150.  
  151.  
  152. Action Items
  153.  
  154.  
  155.    o Matt - will redraft with the suggested changes from the discussion:
  156.  
  157.       -  No compulsion; be neutral
  158.       -  Privacy; tickets readable only by owner and TAC
  159.       -  TAC will mention the ombudsman role
  160.       -  Omit details of ticket format (for now)
  161.       -  Need requirements for TTC
  162.       -  It's ok for 1 ticket to have multiple user dialogs
  163.  
  164.    o Dan/Craig - will clean up draft & submit into the FYI RFC pipeline
  165.  
  166.       -  Check FYI RFC standards to be sure that the ``2 voice'' format
  167.          is acceptable
  168.       -  Provide copy of draft to FARNET's September meeting
  169.  
  170.  
  171. Timetable Through 1990
  172.  
  173.  
  174.  
  175. August              Matt will present revised draft; UCP group to
  176.                     comment
  177.  
  178.                                    3
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185. September           Dan/Craig will incorporate comments, and prepare
  186.                     draft for presentation to FARNET and submission to
  187.                     FYI RFC pipeline
  188. October/November    Collect comments and refine proposal.
  189. December            At IETF meeting, discuss deployment/future plans
  190.  
  191.  
  192.  
  193. Attendees
  194.  
  195.  
  196. Stephen Adams            decwrl::``adams@zeppo''
  197. Eric Carroll             eric@utcs.utoronto.ca
  198. Carol Farnham            carolf@mcescher.unl.edu
  199. Dale Finkelson           dmf@westie.unl.edu
  200. Vince Fuller             fuller@jessica.stanford.edu
  201. Steven Hubert            hubert@cac.washington.edu
  202. Dale Johnson             dsj@merit.edu
  203. Ken Jones                uunet!konkord!ksj
  204. Dan Long                 long@bbn.com
  205. Matt Mathis              mathis@pele.psc.edu
  206. Berlin Moore             prepnet@andrew.cmu.edu
  207. Donald Morris            morris@ucar.edu
  208. Craig Partridge          craig@nnsc.nsf.net
  209. Dana Sitzler             dds@merit.edu
  210. Allen Sturtevant         sturtevant@ccc.nmfecc.gov
  211. Carol Ward               cward@spot.colorado.edu
  212. Robert Woodburn          woody@saic.com
  213.  
  214.  
  215.  
  216.                                    4
  217.